Method and apparatus for multiple slaves to receive data from multiple masters in a data processing system

ABSTRACT

A method, apparatus, and computer instructions for managing requests for data by processes in a data processing system. Requests for data from the processes in slave mode are tracked. Data received by a device driver is stored, wherein the data may originate from multiple masters. The data is sent to the processes, wherein the device driver is not required to handle requests for the processes in slave mode.

CROSS REFERENCE TO RELATED APPLICATION

The present invention is related to the following application entitled“Method and Apparatus for Transferring Data to Virtual Devices Behind aBus Expander”, Ser. No. ______, attorney docket no. AUS920030334US1,filed even date hereof, assigned to the same assignee, and incorporatedherein by reference.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to an improved data processingsystem and in particular to a method and apparatus for processing data.Still more particularly, the present invention provides a method andapparatus for transferring data on a bus between master and slavecomponents.

2. Description of Related Art

A bus is a common pathway, or channel, between multiple devices. Thecomputer's internal bus is known as the local bus, or processor bus.This type of bus provides a parallel data transfer path between the CPUand main memory and to the peripheral buses. A 16-bit bus transfers twobytes at a time over 16 wires; a 32-bit bus uses 32 wires, etc. The busis comprised of two parts: the address bus and the data bus. Addressesare sent over the address bus to signal a memory location, and the datais transferred over the data bus to that location.

Various other types of buses are used in data processing systems. Inparticular, an inter-internal control (IIC) bus is an example of anothertype of bus used in a data processing system. In this bus, one wirecarries a clock signal, while another wire carries the data signal. Thistype of bus is used to provide interconnection between various devices,such as a flexible service processor, a memory, and a control panel. Aflexible service processor is a processing unit that is used toinitialize a data processing system. A flexible service processor hasits own boot code and operating system and may be connected to a numberof I/O devices.

Devices connected to an IIC bus may operate in a master or slave mode.In a master read/write mode, the device may initiate a data transfer.When a device is in a slave read/write mode, the device simply waits fordata coming over the IIC bus. On a flexible service processor, a devicedriver is employed by the flexible service processor to handle datatransfers with the bus. An application executing on a flexible serviceprocessor may make a call to the device driver indicating that theflexible service processor needs to respond as a slave to some eventtriggered by an external master. An external master is a master devicelocated external to the flexible service processor. An example of anexternal master device is a control panel, which may send identifyingbutton pushes on the panel, to the flexible service processor. Anotherexample of an external master device is a rack power controller, whichmay send data, such as temperature data to the flexible serviceprocessor.

More than one master, external to the flexible service processor, maytarget a “virtual slave” in the flexible service processor. With thissituation, more than one event may be issued by different externaldevices at the same time. Further, more than one process executing onthe flexible service processor may be waiting for data on the same bus.A flexible service processor is the slave device and is only able tolisten for data on a single slave address for a particular IIC bus. IICbuses have no intelligence regarding the identity of the mastertriggering the event. As a result, the bus is unable to associate data,put on data lines, with the process waiting for the data.

With this set-up, only one slave transfer request is currently possiblefor a device driver on a flexible service processor. If data for eventsare issued by different master devices, data can be lost if the flexibleservice processor is not continuously set up to receive any data thatmight be put onto the bus. For example, two applications may beexecuting on a flexible service processor in which one applicationmonitors for button pushes on a control panel, while the otherapplication monitors for temperature data from a power device, such as arack power controller. If both the control panel and the rack powercontroller send data, as master devices, on the bus at the same time,the data is directed towards the flexible service processor as the slavedevice. This data can be received by only one of the applicationsbecause the current architecture only allows the device driver for theflexible service processor to handle only one slave request at a time.In this example, both applications cannot issue slave requests that canbe handled by the device driver. As a result, a loss of information mayoccur.

Therefore, it would be advantageous to have an improved method,apparatus, and computer instructions for handling data transfers betweenexternal master devices and internal requests for slave transfers.

SUMMARY OF THE INVENTION

The present invention provides a method, apparatus, and computerinstructions for managing requests for data by processes in a dataprocessing system. Slave mode requests from processes are tracked. Datareceived by a device driver is stored, wherein the data may originatefrom multiple masters. The data is sent to the processes, wherein thedevice driver is not required to handle requests for the processes inslave mode.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are setforth in the appended claims. The invention itself, however, as well asa preferred mode of use, further objectives and advantages thereof, willbest be understood by reference to the following detailed description ofan illustrative embodiment when read in conjunction with theaccompanying drawings, wherein:

FIG. 1 is a pictorial representation of a data processing system inwhich the present invention may be implemented in accordance with apreferred embodiment of the present invention;

FIG. 2 is a block diagram of a data processing system in which thepresent invention may be implemented;

FIG. 3 is a block diagram illustrating functional components used intransferring data between devices;

FIG. 4 is a diagram illustrating components in data flow used invirtualizing slaves in accordance with a preferred embodiment of thepresent invention;

FIG. 5 is a flowchart of a process for handling slave read requests inaccordance with a preferred embodiment of the present invention;

FIG. 6 is a flowchart of a process for identifying and transferring datato virtual slaves in accordance with a preferred embodiment of thepresent invention; and

FIG. 7 is a flowchart of a process for handling data received by adevice driver in accordance with a preferred embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With reference now to the figures and in particular with reference toFIG. 1, a pictorial representation of a data processing system in whichthe present invention may be implemented is depicted in accordance witha preferred embodiment of the present invention. A computer 100 isdepicted which includes system unit 102, video display terminal 104,keyboard 106, storage devices 108, which may include floppy drives andother types of permanent and removable storage media, and mouse 110,Additional input devices may be included with personal computer 100,such as, for example, a joystick, touchpad, touch screen, trackball,microphone, and the like. Computer 100 can be implemented using anysuitable computer, such as an IBM eServer computer or IntelliStationcomputer, which are products of International Business MachinesCorporation, located in Armonk, N.Y. Although the depictedrepresentation shows a computer, other embodiments of the presentinvention may be implemented in other types of data processing systems,such as a network computer. Computer 100 also preferably includes agraphical user interface (GUI) that may be implemented by means ofsystems software residing in computer readable media in operation withincomputer 100.

With reference now to FIG. 2, a block diagram of a data processingsystem is shown in which the present invention may be implemented. Dataprocessing system 200 is an example of a computer, such as computer 100in FIG. 1, in which code or instructions implementing the processes ofthe present invention may be located. Data processing system 200 employsa peripheral component interconnect (PCI) local bus architecture.Although the depicted example employs a PCI bus, other bus architecturessuch as Accelerated Graphics Port (ASP) and Industry StandardArchitecture (ISA) may be used. Processor 202 and main memory 204 areconnected to PCI local bus 206 through PCI bridge 208, PCI bridge 208also may include an integrated memory controller and cache memory forprocessor 202. Additional connections to PCT local bus 206 may be madethrough direct component interconnection or through add-in boards. Inthe depicted example, local area network (LAN) adapter 210, smallcomputer system interface SCSI host bus adapter 212 and flexible serviceprocessor (FSP) processor 214 are connected to PCI local bus 206 bydirect component connection. In contrast, audio adapter 216, graphicsadapter 218, and audio/video adapter 219 are connected to PCI local bus206 by add-in boards inserted into expansion slots.

FSP processor 214 is connected to FSP flash memory 220, FSP dynamicrandom access memory (DRAM) 221, NVRAM 222, and IIC bus controller 223.All of these components form a FSP unit or module. FSP flash memory 220is an example of the flash memory in which microcode used for an initialprogram load (IPL) may be stored. FSP DRAM 221 is a memory in which LIDsor microcode from FSP flash memory 220 are loaded for execution by FSPprocessor 214. NVRAM 222 may be used to hold data that is to be retainedwhen the system is powered down. IIC bus controller 223 provides aninterface to devices, such as a memory, a control panel, and a powerdevice.

SCSI host bus adapter 212 provides a connection for hard disk drive 226,tape drive 228, and CD-ROM drive 230. Typical PCI local busimplementations will support three or four PCI expansion slots or add-inconnectors.

An operating system runs on processor 202 and is used to coordinate andprovide control of various components within data processing system 200in FIG. 2. The operating system may be a commercially availableoperating system such as Windows XP, which is available from MicrosoftCorporation. An object oriented programming system such as Java may runin conjunction with the operating system and provides calls to theoperating system from Java programs or applications executing on dataprocessing system 200. “Java” is a trademark of Sun Microsystems, Inc.Instructions for the operating system, the object-oriented programmingsystem, and applications or programs are located on storage devices,such as hard disk drive 226, and may be loaded into main memory 204 forexecution by processor 202.

Those of ordinary skill in the art will appreciate that the hardware inFIG. 2 may vary depending on the implementation. Other internal hardwareor peripheral devices, such as flash read-only memory (ROM), equivalentnonvolatile memory, or optical disk drives and the like, may be used inaddition to or in place of the hardware depicted in FIG. 2. Also, theprocesses of the present invention may be applied to a multiprocessordata processing system.

For example, data processing system 200, if optionally configured as anetwork computer, may not include SCSI host bus adapter 212, hard diskdrive 226, tape drive 228, and CD-ROM 230. In that case, the computer,to be properly called a client computer, includes some type of networkcommunication interface, such as LAN adapter 210, modem 222, or thelike. As another example, data processing system 200 may be astand-alone system configured to be bootable without relying on sometype of network communication interface, whether or not data processingsystem 200 comprises some type of network communication interface. As afurther example, data processing system 200 may be a personal digitalassistant (PDA), which is configured with ROM and/or flash ROM toprovide non-volatile memory for storing operating system files and/oruser-generated data.

The depicted example in FIG. 2 and above-described examples are notmeant to imply architectural limitations. For example, data processingsystem 200 also may be a notebook computer or hand held computer inaddition to taking the form of a PDA. Data processing system 200 alsomay be a kiosk or a Web appliance.

Turning next to FIG. 3, a block diagram illustrating functionalcomponents used in transferring data between devices is illustrated. Inthis example, application boundary 300 includes applications 302, 304,306, 308, and 310, which may call services through extraction layer 312.Abstraction layer 312 serves as a router for all requests from thedifferent applications. Kernel boundary 314 contains flexible serviceprocessor hardware 316, which may be accessed through different media,such as general purpose input/output (GPIO) 318, universal asynchronousreceiver transmitter (UART) 320, inter-internal control (IIC) 322, jointtest action group (JTAG) 324, universal serial bus (USB) 326, andEthernet 328. Device drivers 330 provide an interface for the physicaldevices in flexible service processor hardware 316.

In these examples, a device driver is present for IIC 322. Presentlyavailable device drivers are only able to handle a single slave requestat any one time for a particular IIC bus. Thus, if multiple devices aresending messages to a flexible service processor on the same bus, someof the data may be lost because the currently available device driver isonly able to handle a single slave request at a time. In other words,only a single application or process on the flexible service processoris able to receive data for that IIC bus.

The present invention provides a method, apparatus, and computerinstructions for allowing multiple slave requests to be handled at thesame time in a flexible service processor system. The mechanism of thepresent invention buffers data received by the device driver by the IICbus. Additionally, the mechanism insures that the flexible serviceprocessor is always ready to receive and respond to events triggered byexternal entities, such as “external master devices”. In this manner,the mechanism of the present invention avoids the loss of data. Further,buffering of incoming data eliminates the need for message data,identifying the master transmitting the message, the mechanism of thepresent invention allows all of the virtual slaves in the flexibleservice processor to see the message.

This mechanism virtualizes applications as slaves. One physical slaveexists, the flexible service processor, in these examples. The virtualslaves are processes or applications executing on the flexible serviceprocessor. The device driver is not required to handle more than oneslave request. In these examples, the slave request is managed by aabstraction layer function and a daemon. A daemon is a program thatexecutes in the background ready to perform an operation when required.An abstraction layer function is a function used to handle requestsdirected towards hardware. This abstraction layer function allows thecaller of the function to make a call without having to know about thespecific hardware. Functioning like an extension to the operatingsystem, a daemon is usually an unattended process that is initiated atstartup or initialization of the data processing system. Typical daemonsare print spoolers and e-mail handlers or a scheduler that starts upanother process at a designated time.

With reference now to FIG. 4, a diagram illustrating components in dataflow used in virtualizing slaves is depicted in accordance with apreferred embodiment of the present invention. In this example, flexibleservice processor unit 400 includes IIC bus controller 402, which servesto provide an interface to one or more IIC buses. In this example,external masters 404, 406, and 408 are attached to the same IIC bus.

Device driver 410 is set to listen to a predefined address as a slavefor any activity occurring over the clock and data lines of the IIC bus.The mechanism of the present invention includes abstraction layerfunction 412 and daemon 414. In these examples, these two components areemployed to create virtual slaves within flexible service processor unit400. Abstraction layer function 412 receives slave requests fromdifferent processes. This abstraction layer performs a routing processto allow for virtualization of slaves in flexible service processor unit400. In these examples, slave mode requests 416, 418, and 420 are sentfrom applications 422, 424, and 426. These requests are placed intoqueue 428 internal to abstraction layer function 412. Each entry intoqueue 428 includes an identification of the application. Otherinformation may also be stored, such as the number of bytes of dataexpected by a particular application.

Daemon 414 is set up to monitor for data received by device driver 410.Daemon 414 reads data through abstraction layer 412 in these examplesfrom device driver 410. This read is performed periodically, such asevery N milliseconds. A suitable value for N may be identified for asystem based on parameters, such as the controller memory and the speedat which the bus is operating. After initialization of flexible serviceprocessor unit 400, daemon 414 is present and runs as long as flexibleservice processor unit 400 is powered in these examples. All datareceived by device driver 410 is stored in buffer 430. The data isbuffered by its arrival sequence and message boundary. Device driver 410is set up or configured such that flexible service processor unit 400 isthe slave. In other words, no change to device driver 410 is needed.Device driver 410 is configured to allow the flexible service processorto respond as a slave at a particular address. In the interrupt handler,as soon as the interrupt is serviced, the setup for next transfer isperformed in such a manner that data is not lost. When the transfer incomplete on the bus, and the data is received by the device driver 410,daemon 414 gathers the data, clears the registers, and sets theregisters for the next transfer. Applications 422, 424, and 426 are thevirtual slaves handled by abstraction layer function 412. When data isreceived in buffer 430, abstraction layer function 412 identifies allrequests located in queue 428. The applications having requests in queue428 are awakened and the data in buffer 430 is broadcast to theprocesses. In these examples, validation of data is handled by eachrespective application, rather than by abstraction layer function 412.If the data does not belong to a particular application, thatapplication may generate another slave read request until theapplication receives the message that the application is waiting forfrom buffer 430.

In this manner, multiple external master devices can send messages tomultiple virtual slaves in a flexible service processor even though theflexible service processor can only occupy a single slave address on thebus. In this manner, multiple virtual slaves may listen to a singleslave address and loss of data is prevented in the instance in whichmultiple masters may send data to the single address.

Turning now to FIG. 5, a flowchart of a process for handling slave readrequests is depicted in accordance with a preferred embodiment of thepresent invention. The process illustrated in FIG. 5 may be implementedin a function, such as abstraction layer function 412 in FIG. 4.

The process begins by receiving a slave read request from an application(step 500). In these examples, the abstraction layer includes anexternal interface used by the applications for requests. Thereafter,the request is placed into a queue (step 502), with the processterminating thereafter. This queue is used to determine whichapplications are to receive the data when a broadcast occurs. Typically,the buffer will be checked for data whenever a request is made.

Turning next to FIG. 6, a flowchart of a process for identifying andtransferring data to virtual slaves is depicted in accordance with apreferred embodiment of the present invention. The process illustratedin FIG. 6 may be implemented in a function, such as abstraction layerfunction 412 in FIG. 4.

The process begins by polling the daemon for data (step 600). Adetermination is then made as to whether data is present in the buffer(step 602). If data is present, applications are identified from slaverequests in the queue (step 604). The data is then broadcast to theapplications identified from the queue (step 606). Thereafter, theprocess waits for a period of time (step 608), and then returns to step600 as described above. The process also proceeds to step 608 if no datais present in the buffer in step 602. Applications having requests inthe queue are woken up with data being broadcast to all of theapplications. The application can keep or discard the data receivedthrough the broadcast. In case the data is discarded, the applicationcan place another request for new data. Alternatively, the daemon orabstraction layer may parse the data based on the identifier string androute the data to the appropriate request.

Turning next to FIG. 7, a flowchart of a process for handling datareceived by a device driver is depicted in accordance with a preferredembodiment of the present invention. The process illustrated in FIG. 7,may be implemented in a process such as daemon 414 in FIG. 4.

The process begins by detecting data received by the device driver (step700). Next, the data is stored in a buffer (step 702), with the processterminating thereafter. This buffer is the one used by the abstractionlayer function to send data to the different virtual slaves.

Thus, the present invention provides a method, apparatus, and computerinstructions for handling multiple slave requests in a device, such as aflexible service processor. The mechanism of the present inventioninsures that the hardware is always configured to receive incoming data.The data is buffered and handled by a daemon process. Processes withinthe device may await for messages targeted for the flexible serviceprocessor. Messages are broadcast to these processes when data isreceived.

It is important to note that while the present invention has beendescribed in the context of a fully functioning data processing system,those of ordinary skill in the art will appreciate that the processes ofthe present invention are capable of being distributed in the form of acomputer readable medium of instructions and a variety of forms and thatthe present invention applies equally regardless of the particular typeof signal bearing media actually used to carry out the distribution.Examples of computer readable media include recordable-type media, suchas a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, andtransmission-type media, such as digital and analog communicationslinks, wired or wireless communications links using transmission forms,such as, for example, radio frequency and light wave transmissions. Thecomputer readable media may take the form of coded formats that aredecoded for actual use in a particular data processing system.

The description of the present invention has been presented for purposesof illustration and description, and is not intended to be exhaustive orlimited to the invention in the form disclosed. For example, in theillustrations, a daemon and an abstraction layer function are used toimplement the processes of the present invention. Depending on theparticular implementation, these processes could be placed in a singlecomponent, such as in the abstraction layer function or in an entirelydifferent component. Further, these processes could be implemented inmore than two components depending on the particular implementation.Many modifications and variations will be apparent to those of ordinaryskill in the art. The embodiment was chosen and described in order tobest explain the principles of the invention, the practical application,and to enable others of ordinary skill in the art to understand theinvention for various embodiments with various modifications as aresuited to the particular use contemplated.

1.-12. (canceled)
 13. A data processing system for managing requests fordata by processes, the data processing system comprising: a singlephysical device that is operating in slave mode for receiving requestsfor data from a plurality of processes; the single physical devicehaving a single slave address listening for data on a physical bus thatis addressed to the single slave address a plurality of master devicescommunicating with the single physical device using only the singleslave address; a device driver that is included in the single physicaldevice receiving data from the physical bus that is addressed to thesingle slave address; storing means for storing data received by thedevice driver from ones of the plurality of master devices as storeddata; sending means for sending the stored data to the plurality ofprocesses, wherein the device driver is not required to handle requestsfor the plurality of processes while the single physical device isoperating in the slave mode; an abstraction layer within the singlephysical device; the abstraction layer receiving the requests for datafrom the plurality of processes; a queue that is included in theabstraction layer for storing each one of the requests including anidentification of one of the plurality of processes that made therequest; in response to the stored data being present in a buffer theabstraction layer identifying all of the requests that are in the queue;the queue for identifying all of the plurality of processes that madethe requests in the queue; the abstraction layer awakening all of theidentified plurality of processes; and the abstraction layerbroadcasting all of the stored data to all of the identified pluralityof processes. 14.-16. (canceled)
 17. The data processing system of claim13, further comprising in response to a receipt of data by the devicedriver, a daemon for storing the received data in a buffer to form thestored data; and in response to storing the received data in the buffer,the daemon resetting the device driver so that the device driver isready to start receiving new data, wherein, after receipt of data, thedevice driver does not process the data and remains continually ready toreceive new data.
 18. (canceled)
 19. The data processing system of claim13, wherein the requests are slave read requests.
 20. The dataprocessing system of claim 13, wherein the plurality of processes arevirtual slaves.
 21. (canceled)